home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1993 / Internet Info CD-ROM (Walnut Creek) (1993).iso / inet / ietf / iplpdn / iplpdn-minutes-91mar.txt < prev    next >
Encoding:
Text File  |  1993-02-17  |  13.3 KB  |  376 lines
  1.  
  2.  
  3. CURRENT_MEETING_REPORT_
  4.  
  5.  
  6. Reported by George Clapp/Ameritech
  7.  
  8. IPLPDN Minutes
  9.  
  10. Opening Remarks
  11.  
  12. This was the second meeting of the IP over Large Public Data Networks
  13. Working Group and the following was the Agenda of the meeting:
  14.  
  15.  
  16.    o Wednesday, March 13, 1991
  17.  
  18.       -  Tutorial on Frame Relay (FR) by Andy Malis
  19.       -  Discussion of encapsulation and protocol multiplexing over FR
  20.       -  Tutorial on ISDN (Wayne Heinmiller and Jim Loehndorf)
  21.       -  Discussion of encapsulation and protocol multiplexing over ISDN
  22.  
  23.    o Thursday, March 14, 1991
  24.  
  25.       -  Joint meeting with the BGP Working Group to discuss the use of
  26.          BGP for routing and address resolution (Paul Tsuchiya)
  27.       -  Continued discussion of encapsulation and protocol multiplexing
  28.  
  29.  
  30. Frame Relay Tutorial
  31.  
  32. Due to airplane troubles, Andy Malis had been unable to present his
  33. tutorial on Frame Relay during the plenary the previous evening, so he
  34. kindly presented his talk during the first half of Wednesday morning's
  35. Working Group session.  (Andy also presented this tutorial during the
  36. Friday morning plenary, and a copy of his presentation is included in
  37. the Proceedings for that session.  A postscript version is online for
  38. anonymous ftp at ``pub/ietf-frame-relay-intro.ps'' on ccv1.bbn.com) The
  39. presentation was an excellent preparation for the discussion of
  40. encapsulation and protocol multiplexing.
  41.  
  42. Encapsulation and Protocol Multiplexing for Frame Relay
  43.  
  44. After the tutorial Caralyn Brown presented the following encapsulation
  45. and protocol multiplexing scheme for Frame Relay.  The proposal is
  46. documented in the draft ``Multiprotocol Interconnect over Frame Relay
  47. Networks'', which is available online on ccv1.bbn.com for anonymous ftp
  48. as ``pub/multiprotocol.txt''.  (A copy of the viewgraphs of Caralyn's
  49. presentation accompanies these minutes.)
  50.  
  51.                                    1
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58.                          +--------------------+
  59.                          |  LAPD flag (0x7E)  |
  60.                          +--------------------+
  61.                          |        DLCI        |
  62.                          +--------------------+
  63.                          |        DLCI...     |
  64.                          +--------------------+
  65.                          |  Format Identifier |
  66.                          +--------------------+
  67.                          |FCSP| Origin_Media  |
  68.                          +--------------------+
  69.                          |        ...         |
  70.                          +--------------------+
  71.                          |        Info        |
  72.                          +--------------------+
  73.                          |        ...         |
  74.                          +--------------------+
  75.                          |  Frame Ck Sequence |
  76.                          +--------------------+
  77.                          |  Frame Ck Sequence |
  78.                          +--------------------+
  79.                          |  LAPD flag (0x7E)  |
  80.                          +--------------------+
  81.  
  82.  
  83.  
  84. FCSP: Frame Check Sequence Preservation
  85.  
  86. The Format Identifier indicates whether 802.2 and SNAP or a bridged MAC
  87. frame follows, and the Origin_Media indicates the type of the bridged
  88. MAC frame.  If a routed packet is being carried, then the Origin_Media
  89. value is set to zero and the 802.2 LLC Type 1 and SNAP headers follow.
  90. The Ethertype of the SNAP header is used to indicate the type of the
  91. routed packet.  This proposal was modified by Charles Carvalho, who
  92. proposed that the 802.2/SNAP headers be eliminated by carrying both the
  93. bridged MAC frame type and the Ethertype values within a combined Format
  94. Identifier/Origin_Media field.  There was qualified acceptance of this
  95. approach before the group broke for lunch.
  96.  
  97. ISDN Tutorial and Proposal
  98.  
  99. Wayne Heinmiller with Jim Loehndorf presented an overview tutorial on
  100. ISDN (a copy of the presentation accompanies these minutes).  The
  101. presentation led into a talk by Dory Leifer of proposed encapsulation,
  102. protocol multiplexing, and fragmentation schemes for circuit and LAPD
  103. ISDN. The proposal is documented in the draft ``A Subnetwork Control
  104. Protocol for ISDN Circuit-Switching'', which is available online on
  105. terminator.cc.umich.edu as `` ftp/isdn'' for anonymous ftp.  Further
  106. discussion was deferred until the next morning.
  107.  
  108.  
  109.  
  110.                                    2
  111.  
  112.  
  113.  
  114.  
  115.  
  116.  
  117. Joint Meeting with BGP Working Group
  118.  
  119. Paul Tsuchiya led a joint meeting of the IPLPDN and BGP Working Groups.
  120. (A copy of his slides accompany the minutes.)  Paul proposed alternative
  121. mechanisms to support a simple and effective way for routers to obtain
  122. routing and address resolution information from BGP servers.  He also
  123. proposed an extension to BGP in which both the next hop IP address and
  124. the hardware, or SubNetwork Point of Attachment (SNPA), address would be
  125. given to the requesting router.
  126.  
  127. Members of the BGP group were concerned with potential conflicts between
  128. policies of the Autonomous Systems that might be traversed by a packet.
  129. This discussion remained unresolved and Paul volunteered to work towards
  130. a solution in time for the next meeting.
  131.  
  132. Encapsulation and Protocol Multiplexing
  133.  
  134. After the break, IPLPDN met separately from the BGP Working Group and
  135. Caralyn Brown presented the modified proposal for encapsulation and
  136. protocol multiplexing over Frame Relay.  (A copy of the viewgraph of the
  137. proposal accompanies the minutes.)
  138.  
  139.  
  140.                          +--------------------+
  141.                          |  LAPD flag (0x7E)  |
  142.                          +--------------------+
  143.                          |        DLCI        |
  144.                          +--------------------+
  145.                          |        DLCI...     |
  146.                          +--------------------+
  147.                          |  Format ID 1       |
  148.                          +--------------------+
  149.                          |  Format ID 2       |
  150.                          +--------------------+
  151.                          |        ...         |
  152.                          +--------------------+
  153.                          |        Info        |
  154.                          +--------------------+
  155.                          |        ...         |
  156.                          +--------------------+
  157.                          |  Frame Ck Sequence |
  158.                          +--------------------+
  159.                          |  Frame Ck Sequence |
  160.                          +--------------------+
  161.                          |  LAPD flag (0x7E)  |
  162.                          +--------------------+
  163.  
  164.  
  165.  
  166.                                    3
  167.  
  168.  
  169.  
  170.  
  171.  
  172.  
  173. If the value of the Format Identifier is less than 1024 decimal (0x0400)
  174. then the field is used to encode the MAC type and the code points are
  175. identical to those in internet-draft ``Point to Point Protocol
  176. Extensions for Bridging''.  This is shown below.
  177.  
  178.  
  179.        0                                      1
  180.        0   1   2   3   4   5   6   7   8   9   0   1   2   3   4   5
  181.      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
  182.      | 0 | 0 | 0 | 0 | 0 | 0 | F | Z |          MAC TYPE             |
  183.      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
  184.  
  185.  
  186.  
  187. The F bit is used to indicate the presence of the MAC Frame Check
  188. Sequence, and the Z bit is used to indicate zero compression.
  189.  
  190. If the value of the Format Identifier is 1024 decimal (0x0400) then the
  191. 802.2 LLC header follows the Format Identifier field, as shown below.
  192.  
  193.  
  194.        0                                      1
  195.        0   1   2   3   4   5   6   7   8   9   0   1   2   3   4   5
  196.      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
  197.      | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
  198.      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
  199.      |              DSAP             |             SSAP              |
  200.      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
  201.      |            Control            |
  202.      +---+---+---+---+---+---+---+---+
  203.  
  204.  
  205.  
  206. If the value of the Format Identifier is greater than 1024 decimal
  207. (0x0400) then the encoded Format Identifier is equivalent to the
  208. Digital-Intel-Xerox (DIX) Ethertype, as shown below.
  209.  
  210.  
  211.        0                                      1
  212.        0   1   2   3   4   5   6   7   8   9   0   1   2   3   4   5
  213.      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
  214.      |               Digital-Intel-Xerox (DIX) Ethertype             |
  215.      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
  216.  
  217.  
  218.  
  219. Caralyn continued with a discusion of mechanisms for address resolution
  220. and proposed that ARP be used to discover the DLCI associated with an IP
  221.  
  222.                                    4
  223.  
  224.  
  225.  
  226.  
  227.  
  228.  
  229. address.  She also proposed an extension to ARP named Inverse ARP to
  230. discover the IP address associated with a DLCI. This latter proposal is
  231. documented in the draft ``Inverse Address Resolution Protocol'', which
  232. is available online by anonymous ftp on ccv1.bbn.com as
  233. ``pub/inarp.txt''.
  234.  
  235. After some discussion and modifications, all of these proposals appeared
  236. to be acceptable to the group.
  237.  
  238. IP over ISDN
  239.  
  240. Dory Leifer continued with a discussion of the following issues:
  241.  
  242.  
  243.    o Fragmentation - do we need it considering the access network may
  244.      impose small max frames?
  245.      Resolution:  further study
  246.  
  247.    o End-to-end link state for switched access, i.e., XID frames?
  248.      Resolution:  no
  249.  
  250.    o ACK mode support or at least include CONTROL field for Q.921
  251.      compatibility?
  252.      Resolution:  the group accepted the CONTROL field with a pad in the
  253.      encapsulation scheme.  The revised scheme is shown below.
  254.  
  255.  
  256.                                    +-----------+
  257.                                    |   flag    |
  258.                        +-----------+-----------+
  259.                        |   DLCI    |  DLCI..   |
  260.                        +-----------+-----------+
  261.                        |  Control  |    PAD    |
  262.                        +-----------+-----------+
  263.                        | Format ID | Format ID |
  264.                        +-----------+-----------+
  265.                        |   info..  |   ...     |
  266.                        +-----------+-----------+
  267.                        |    ...    |   ...     |
  268.                        +-----------+-----------+
  269.                        |    CRC    |    CRC    |
  270.                        +-----------+-----------+
  271.                        |   flag    |
  272.                        +-----------+
  273.  
  274.  
  275.    o Discovery protocol of Max frame size?
  276.      No resolution
  277.  
  278.  
  279.  
  280.                                    5
  281.  
  282.  
  283.  
  284.  
  285.  
  286.  
  287.    o Code point for in-connection management protocol?
  288.      No resolution
  289.  
  290.  
  291. At this point, time ran out and the group adjourned until the next
  292. meeting in Atlanta, GA, in July 1991.
  293.  
  294. Attendees
  295.  
  296. Karl Auerbach            karl@eng.sun.com
  297. William Babson           bill%penril@uunet.UU.NET
  298. Fred Baker               fbaker@emerald.acc.com
  299. Atul Bansal              bansal@netrix.nac.dec.com
  300. Ron Bhanukitsiri         rbhank@wsl.dec.com
  301. Caralyn Brown            cbrown@wellfleet.com
  302. Howard Brown             brown@ctron.com
  303. Theodore Brunner         tob@thumper.bellcore.com
  304. Lida Carrier             lida@apple.com
  305. Eric Carroll             eric@utcs.utoronto.ca
  306. Charles Carvalho         charles@sage.acc.com
  307. Martina Chan             mchan@mot.com
  308. Cho Chang                chang_c@apollo.hp.com
  309. George Clapp             clapp@uunet.uu.net
  310. Graham Cobb              cobb@marvin.enet.dec.com
  311. Richard Colella          colella@osi3.ncsl.nist.gov
  312. Nabil Damouny
  313. Tom Easterday            tom@cic.net
  314. Gus Elmer                arch1!ae@att.com
  315. Dennis Ferguson          dennis@canet.ca
  316. Peter Ford               peter@lanl.gov
  317. Daniel Friedman          danfriedman@bbn.com
  318. Charles Gallucci
  319. Dave Geurs               dgeurs@mot.com
  320. Bret Gorsline            jinx@engin.umich.edu
  321. Martin Gray              mg@spider.co.uk
  322. Olafur Gudmundsson       ogud@cs.umd.edu
  323. Frank Heath
  324. Kathleen Huber           khuber@bbn.com
  325. B.V. Jagadeesh           bvj@esd.3com.com
  326. Dan Jordt                danj@nwnet.net
  327. Ajay Kachrani            kachrani@regent.enet.dec.com
  328. Manu Kaycee              kaycee@trlian.enet.dec.com
  329. Nam Keung
  330. Peter Kirstein           kirstein@cs.ucl.ac.uk
  331. Mary Louise Laier        laierl@applelink.apple.com
  332. Michelle Landriault      crm57a@bnr.ca
  333. Joseph Lawrence          jcl@sabre.bellcore.com
  334. Dory Leifer              Dory.Leifer@terminator.cc.umich.edu
  335. Richard Libby            libby@c10sd6.stpaul.ncr.com
  336. Mike Little              little@ctt.bellcore.com
  337. Then Liu
  338.  
  339.                                    6
  340.  
  341.  
  342.  
  343.  
  344.  
  345.  
  346. John LoVerso             loverso@westford.ccur.com
  347. Andrew Malis             malis@bbn.com
  348. Glenn McGregor           ghm@merit.edu
  349. Robert Meierhofer        bobm@cl0sd6.stpaul.ncr.com
  350. Linda Melvin             infopath@well.sf.ca.us
  351. Agnes Moran
  352. Robert Peglar            robp@anubis.network.com
  353. James Philippou          japhilippou@eng.xyplex.com
  354. Rehmi Post               rehmi@ftp.com
  355. Stephanie Price          price@cmc.com
  356. Ron Roberts              roberts@jessica.stanford.edu
  357. Manoel Rodrigues         manoel.rodrigues@att.com
  358. Allyn Romanow            allyn@eng.sun.com
  359. Allan Rubens             acr@merit.edu
  360. Ray Samora               rvs@proteon.com
  361. Paul Selkirk             paul@ftp.com
  362. Marc Sheldon             ms@Germany.eu.net
  363. Daisy Shen               daisy@watson.ibm.com
  364. Stephen Shew             sdshew@bnr.ca
  365. William Townsend         townsend@xylogics.com
  366. Paul Tsuchiya            tsuchiya@bellcore.com
  367. Robert Ullmann           ariel@relay.prime.com
  368. Kannan Varadhan          kannan@oar.net
  369. Francis Waldman
  370. Wing Fai Wong            wfwong@malta.sbi.com
  371. Chin Yuan                cxyuan@pacbell.com
  372.  
  373.  
  374.  
  375.                                    7
  376.